home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re(2) Converting MacApp Exampl < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  2.3 KB  |  [TEXT/ttxt]
  1. Subject:     Re(2): Converting MacApp Example to ODF
  2. Sent:        5/31/96 11:05 AM
  3. Received:    5/31/96 11:21 AM
  4. From:        Mark Lanett, mlanett@meer.net
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. At 10:00 AM 5/31/96, John Major wrote:
  9. >On this note, then, I have to say that conspicuously absent from the picture
  10. >so far is a tool to move MA views to ODF, or better yet, to use them
  11. >simultaneously with both frameworks (given the excellent tools on the MA
  12. >side). There was even a note in the early Vger docs to the tune of "I'm going
  13. >to drop MA support, because I don't know anyone who's interested in this" -
  14. >ARGH!
  15.  
  16. Oops. You know, when I did Vger I didn't think about using it as a
  17. migration tool at all. I simply looked at Ad Lib and Constructor and
  18. decided that Constructor was the superior view editor, hence the one to
  19. support. Also the PP view model is closer to the ODF view model. I later
  20. discovered people wanted to use it as a migration tool; however I never did
  21. implement custom view classe support, and Vger is now obsolete anyway
  22. (plus, I accidentally deleted the source code).
  23.  
  24. But on the plus side, we have done experimental work having the ability to
  25. read PP view resources in the framework. We'll probably pull it out and
  26. have it available as a separate "conversion" part. This is similar to what
  27. Vger did, only it would generate resources, not code. With MacApp view
  28. support it would work as an MA conversion tool as well.
  29.  
  30. We haven't really though about hosting MacApp view source code in ODF,
  31. although it could probably be done as an add-on (i.e. not bloating the
  32. framework for those who don't need it). And while many classes are similar
  33. (TEventHandler/TBehavior & FW_CEventHandler), they have different names and
  34. methods. I suppose if you step back it seems stupid to have similar classes
  35. having different interfaces. It's really ironic when you consider that ODF
  36. is descended from Bedrock, once itself viewed as the successor to MacApp.
  37. Clearly the issue of code migration managed to miss a number of us.
  38.  
  39. Anyway, we're much more aware of it all now. The ODFLibrary you heard about
  40. is a planned attempt to stop future code differentiation by reusing the
  41. cross-platform non-opendoc stuff from ODF in MacApp. Doesn't solve the
  42. legacy code problem, but it is a start.
  43.  
  44.  
  45. Mark Lanett, ODF
  46.  
  47.